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What  Is  the  SEI  Product  Line 
Technical  Probe  (PLTP)? 


A  method  for  examining  an 
organization’s  readiness  to  adopt  or 
ability  to  succeed  with  a  software 
product  line  approach 

•  diagnostic  tool  based  on  the  SEI 
Framework  for  Software  Product 
Line  Practice 

•  The  product  line  practice  areas 
from  the  Framework  are  the  basis 
of  data  collection  and  analysis. 
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SEI  PLTP  Outcomes 

Set  of  findings  that  portray  organizational 

•  strengths 

•  challenges 

with  regard  to  a  product  line  approach 

Findings  are  documented  in  a  findings  presentation  and  in 
a  formal  PLTP  Findings  Report. 

Findings  can  be  used  to  develop  an  adoption  plan  or 
action  plan  with  the  goal  of  making  the  organization  more 
capable  of  achieving  product  line  success. 
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What  is  the  SEI  Framework  for 
Software  Product  Line  PracticeSM  ? 


The  SEI  Framework  for  Software  Product  Line  Practice  is 
a  conceptual  framework  that  describes  the  essential 
activities  and  twenty-nine  practice  areas  necessary  for 
successful  software  product  lines. 


The  Framework,  originally  conceived  in  1998,  is  evolving 
based  on  the  experience  and  information  provided  by  the 
community. 


]  Software 
Product  Lines 


Version  4.0  -  in  Software  Product  Lines: 
Practices  and  Patterns 


Pnctioj 

and 

Patterns 


■  ■  ‘ 


Linda  NortEiivp 


Version  4.2  - 
http://www.sei.cmu.edu/productlines/framework.html 
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Core  Asset 
Development 


SEI  Framework 


Product 

Development 


Management 

Essential  Activities 


Architecture  Definition 

Configuration  Management 

Building  a  Business  Case 

Architecture  Evaluation 

Data  Collection,  Metrics, 

Customer  Interface  Management 

Component  Development 

and  Tracking 

Developing  an  Acquisition 

COTS  Utilization 

Make/Buy/Mine/Commission 

Analysis 

Strategy 

Funding 

Mining  Existing  Assets 

Process  Definition 

Launching  and  Institutionalizing 

Requirements  Engineering 

Scoping 

Market  Analysis 

Software  System  Integration 

Technical  Planning 

Operations 

Testing 

Technical  Risk  Management 

Organizational  Planning 

Understanding 

Relevant  Domains 

Tool  Support 

Organizational  Risk  Management 
Structuring  the  Organization 
Technology  Forecasting 

Training 

Software 

Technical 

Organizational 

Engineering 

Management 

Management 

©  2005  by  Carnegie  Mellon  University 


Practice  Areas 


page  6 


Carnegie  Mdlun 

Software  Engineering  Institute 


Applying  the  Practice  Areas  in  the 
PLTP 


The  PLTP  process  uses  structured  stakeholder 
interviews  based  on  questions  derived  from  the 
29  practice  areas. 
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Who  Are  the  Stakeholders? 


Executives 

Managers 

Architects 

Developers 


Technical  support  staff 
Marketers 

Customers/End  users 
Engineers 
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How  is  a  PLTP  Executed? 

Preliminary  Phase 

•  one-day  meeting  at  customer  site 

•  probe  preparation 

Technical  Probe  Phase 

•  data  gathering 

•  data  consolidation  and  analysis 

•  reporting 

•  four  days  at  customer  site 


Follow-On 

•  report  writing 

•  optional:  facilitated  development  of  action  plan  to  address 
findings 

•  optional:  tailored  assistance 
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PLTP  Applicability 

When  an  organization 

•  is  considering  adopting  a  software  product  line 
approach 

•  has  already  initiated  a  software  product  line 
approach 
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History  of  the  SEI  PLTP 

The  PLTP  was  created  in  2000  in  response  to  requests  to 
evaluate  the  product  line  fitness  of  several  organizations. 

•  original  PLTP  question  bank  was  derived 

•  process  was  created 

•  other  SEI  diagnostics  and  earlier,  less  formal  product  line 
diagnostics  were  used  as  the  basis 

•  question  bank  and  process  were  continuously  improved 
based  on  early  applications 

•  team  training  materials  and  templates  were  developed 

In  2002,  we  created  the  SEI  Adoption  Factory  Pattern  and 
subsequently  modified  the  PLTP  to  use  the  Adoption  Factory 
Pattern  in  both  the  PLTP  data  analysis  and  findings  reports. 

The  PLTP  has  been  used  to  examine  a  variety  of  government 
and  commercial  organizations. 
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Sample  Breadth  of  PLTP  Experience 


Domain 

Size  of 
Organization 

Business  Drivers  for  Software 
Product  Line  Approach 

collaborative  planning 

small 

Improve  interoperability;  reduce 
ownership  costs;  reduce 
development  time 

hardware  diagnostics 

small 

Reduce  ownership  costs;  reduce 
development  cost  and  time 

military  training 
Droducts 

medium 

Ensure  commonality  across 
systems;  reduce  ownership  costs 

automotive  multimedia 

large 

Reduce  development  costs; 
formalize  approach  to  reuse 

engine  controllers 

large 

Reduce  complexity  and  costs;  enter 
other  market  segments 

automotive  products 

large 

Reduce  complexity;  address  staff 
shortages 

military  command  and 
control  (two) 

large 

Reduce  time  to  field;  reduce 
maintenance  costs;  reduce 
duplication 

automated  tellers 

large 

Improve  productivity,  performance 
and  quality;  reduce  defects 
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Why  Organizations  Arrange  For  a  PLTP 

To  take  a  baseline  snapshot  of  the  product  line 
organization 

To  do  a  reality  check 

To  avoid  common  pitfalls 

To  capitalize  on  strengths 

To  shore  up  weaknesses 

To  identify  and  mitigate  risks  early 

To  get  stakeholder  buy-in 
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PLTP  Findings 

A  PLTP  team  produces  findings  for  each  of  the  29  practice 
areas 

•  based  on  the  interviews  and  document  examination 

•  expressed  as  strengths  and  challenges 

•  rated  (High,  Medium,  Low)  based  on  relative 
importance  of  the  findings  for  the  practice  area  at  the 
time  of  the  PLTP 

In  addition,  the  findings  include  recommendations  and  the 
caution  that  despite  individual  ratings,  eventually  all 
practice  areas  would  have  to  be  addressed  thoroughly. 
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Early  PLTP  Findings:  Common  Themes 

All  of  the  early  organizations  were  at  the  beginning  stages 
of  product  line  adoption  or  exploration. 

In  all  cases,  the  management  challenges  included 

•  Building  a  Business  Case 

•  Scoping 

•  Process  Definition 

•  Launching  and  Institutionalizing 

•  Structuring  the  Organization 

The  software  engineering  challenges  typically  included 

•  Architecture  Definition 

•  Architecture  Evaluation 

•  Requirements  Engineering 
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Early  PLTP  Findings:  Tuning  Needed 

The  findings  were  listed  by  practice  area. 

There  was  no  higher  level  structuring. 

The  practice  area  ratings  were  derived  largely  from  the  expertise 
of  the  PLTP  team. 

As  a  result, 

•  The  findings  were  difficult  for  organizations  to  digest. 

•  How  to  proceed  was  often  not  obvious. 

•  The  process  and  results  were  not  as  repeatable  as  desired. 

Although  the  PLTP  was  deemed  useful,  more  was  needed. 

•  Organizations  wanted  some  sort  of  a  product  line  roadmap. 

•  The  PLTP  Findings  Report  needed  better  organization. 

•  The  themes  that  emerged  from  the  early  PTLP  experiences 
provided  powerful  input. 
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A  Roadmap  and  an  Aid  for  the  PLTP 

The  SEI  had  defined  software  product  line  practice 
patterns  to  assist  in  planning  and  effecting  product  line 
adoption. 

One  of  these  patterns,  the  Factory  Pattern,  already 
provided  a  high-level  view  of  the  a  product  line 
organization  in  terms  of  sub-patterns,  which  are  ultimately 
expressed  as  practice  areas. 

We  created  a  variant  of  the  Factory  Pattern  with  some 
useful  views  to  provide  both  a  generic  product  line 
roadmap  and  a  new  organizing  structure  for  PLTP  final 
analysis  and  report  of  findings. 
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The  Adoption  Factory  Pattern 

Establish  |  Establish  |  Operate 


Informs 
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Associated  Practice  Areas 

Establish  ■  Establish  Production 

Context  _ _ Capability 

|  Requirements  Engineering 


Operate 
Product  Line 


Marketing  Analysis 
Understanding  Relevant 
Domains 

Technology  Forecasting 
Building  a  Business  Case 
Scoping 


|  Architecture  Definition 
I  Architecture  Evaluation 
I  Mining  Existing  Assets 
Component  Development 
|  COTS  Utilization 
■  Software  System  Integration 
I  Testing 


Requirements  Engineering 
Architecture  Definition 
Architecture  Evaluation 
Mining  Existing  Assets 
Component  Development 
COTS  Utilization 
Software  System  Integratio 
Testina 


Process 


Process  Definition 


OrganizaHmL 


]  Make/Buy/Mine/Commission 

■  Configuration  Management  . 
|  Tool  Support 

|  Data  Collection,  Metrics,  Tracking! 
I  Technical  Planning 
j  Technical  Risk  Management 


Launching  and  Institutionalizing 
Funding 

Structuring  the  Organization 
Operations 
Organizational  Planning 
Customer  Interface  Management 
Organizational  Risk  Management 
Developing  an  Acquisition 
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PLTP  and  the  Adoption  Factory 
Pattern 

We  still  use  practice  areas  as  the  primary  reference  for 
data  collection  and  analysis. 

We  do  a  final  analysis  against  the  Adoption  Factory 
pattern  using  all  of  its  associated  views  (practice  areas, 
phases,  focus  areas,  roles,  and  outputs). 

We  report  findings  using  the  Adoption  Factory  pattern  as 
an  organizing  structure. 

We  demonstrate  cross-practice  area  challenges  using  the 
Adoption  Factory  pattern. 
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Recent  Findings:  Common  Themes  - 1 

The  organizations  that  are  requesting  a  PLTP  are  for  the 
most  part  better  informed  about  software  product  lines. 

Engineering  organizations  tend  to  jump  right  into 
architecture  and  component  development  activities  without 
doing  a  proper  scoping  and  business  case. 

•  Frustration  and  waste  result. 

There  is  still  a  pervading  assumption  that  product  lines 
involve  a  new  technical  approach  only. 

•  There  is  too  little  awareness  that  a  product  line 
approach  is  both  a  new  technical  and  business 
approach. 
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Recent  Findings:  Common  Themes  -  2 

Most  organizations  vastly  underestimate  the  management 
commitment  and  involvement  needed.  They  fail  to  have 

•  a  responsible  product  line  manager  with  authority  to 
oversee  the  product  line  effort 

•  a  product  line  adoption  plan 

•  a  product  line  concept  of  operations 

•  a  training  plan 

•  an  appropriate  funding  model 

Organizations  with  more  product  line  sophistication 
struggle  with 

•  configuration  management 

•  appropriate  variation  mechanisms 

•  a  production  plan  used  to  build  all  products 

•  appropriate  data  collection,  metrics,  and  tracking 
activities 
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Typical  Engineering  Organization 
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I  Software  System  Integration 
Testing 
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I  Software  System  Integration 
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Process 


- -  ~  --h- - 
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Organization 
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Typical  Challenges  (shown  in  red) 
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Reactions  to  PLTP  Results: 
General 

Interviewed  stakeholders  universally  have  more  buy-in  to  their 
organization’s  product  line  effort. 

Managers/sponsors  of  the  PLTP  have  in  every  case  been 
satisfied  that  they  received  a  helpful  and  better  understanding  of 
their  product  line  readiness  and  what  is  needed  to  get  to  full 
product  line  operations. 

All  organizations  engaged  the  SEI  to  conduct  follow-on  planning 
sessions  to  determine  how  to  proceed  based  on  the  PLTP 
findings. 

Organizations  have  found  the  Adoption  Factory  pattern  to  be  a 
very  helpful  organizing  structure  and  guide  for  planning. 


©  2005  by  Carnegie  Mellon  University 


page  30 


CarnejfieMdkm 

Software  Engineering  Institute 


Reactions  to  PLTP  Results:  Specific 

Of  the  nine  organizations  depicted  earlier 

•  One  decided  to  abandon  the  product  line  approach;  the 
challenges  were  too  daunting. 

•  One  deferred  work  on  the  product  line  effort  in  order  to 
establish  a  firmer  basis  of  process  discipline. 

-  The  product  line  effort  was  reactivated  after  successful 
process  improvement  activities. 

•  Two  are  struggling  in  the  initial  stage  of  launching  a  product 
line. 

•  One  has  incorporated  its  product  line  effort  into  the  context  of 
a  larger,  subsuming  enterprise  effort. 

•  Four  are  making  aggressive  progress  in  their  product  line 
efforts. 

•  Two  are  planning  on  a  second  PLTP  to  measure  their 
progress  against  their  initial  baseline. 


©  2005  by  Carnegie  Mellon  University 


page  31 


Carnegie  Mdlun 

Software  Engineering  Institute 


Today’s  Presentation 

Overview  of  the  SEI  Product  Line  Technical 
Probe  (PLTP) 

Experience  Using  the  PLTP 

•  Early  experiences 

•  Midcourse  change 

•  Recent  experiences 

Organizations’  Reactions  to  PLTP  Findings 
Conclusions 


©  2005  by  Carnegie  Mellon  University 


page  32 


CarnejfieMdkm 

Software  Engineering  Institute 


Conclusions 

The  SEI  Product  Line  Technical  Probe  is  an  effective  means  for 
understanding  an  organization’s  readiness  to  proceed  with  a 
product  line  effort. 

The  PLTP  provides  a  solid  basis  for  developing  a  product  line 
adoption  plan. 

The  PLTP  led  the  SEI  to  create  the  Adoption  Factory  pattern. 

The  Adoption  Factory  pattern  is  an  effective  roadmap  for  product 
line  adoption  and  for  reporting  and  prioritizing  PLTP  findings. 

Most  organizations  who  have  applied  the  PLTP  currently  have 
product  line  efforts  underway. 
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Questions  -  Now  or  Later 


Linda  Northrop 

Director 

Product  Line  Systems  Program 
Telephone:  412-268-7638 
Email:  lmn@sei.cmu.edu 

U.S.  mail: 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 

World  Wide  Web: 

http://www.sei.cmu.edu/ata 

http://www.sei.cmu.edu/plp 

SEI  Fax:  412-268-5758 


Business  Development 
Product  Line  Systems  Program 

Jay  Douglass 
Telephone:  412-268-6834 
Email:  icd@sei.cmu.edu 
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